docs(packaging): "signs with your own MOK" is measured, and says what happens without one (Refs #1280) - #1400

…he harness prints

Self-audit of the section this PR edits: the three install rows still claimed 24/22/22 rows PASS, which
was right when #1324 merged and is wrong on this branch, where the harness emits 31 (deb) and 29 (rpm,
arch) after the restore, kernel-removal and memlock rows. A row that tells the reader to run
scripts/pkg-proof.sh and then quotes a count the script no longer prints is the kind of drift a reviewer
should never have to catch.

Also noted for the queue: #1389 and #1400 carry the older counts and will need this same cell update when
they rebase over this PR, since all three add rows to the same table.

… back" (Refs #1280) (#1419)

* pkg-proof: prove the other half of 'uninstall puts the in-tree driver back'

I have written that sentence three times and only ever proved the first half ('no module left
behind'). The second half is the one a user notices: while our package is installed dkms archives the
distribution's own amdxdna into /var/lib/dkms/<pkg>/original_module/ and removes it from the tree, so
removal has to restore it.

Measured by hand first, then as two rows in the harness (all three families, after the purge):

  the in-tree amdxdna resolves again    modprobe -S <kv> --show-depends amdxdna lands on
                                        /lib/modules/<kv>/kernel/drivers/accel/amdxdna/amdxdna.ko*
  the in-tree module file is restored   that file exists again

deb 26/26 rows PASS, rpm 24/24, arch 24/24, PROOF-RC=0. The first attempt at this row failed on both
deb and rpm and both were my bug, not the packages: I compared find's output with modprobe's and
treated an empty find as 'not restored' — the detail line already said modprobe had gone back to the
kernel/ path. The row now asks each question separately, which is also what the docs claim.

Refs #1280.

* pkg-proof: remove the kernel package too — 'and uninstall cleanly' had no evidence for that half

Every family's proof installed the kernel package and then removed only this set, so the kernel half of
'uninstall cleanly' was an untested claim. Three rows, after the restore rows:

  the kernel package removes    dpkg -P / rpm -e / pacman -R, rc=0
  the kernel image is gone      /boot/vmlinuz-7.4.0-rc1-1bit (Arch: /boot/vmlinuz-1bit)
  the module tree is gone       0 files under modules/7.4.0-rc1-1bit

Measured: deb 29/29 rows PASS, rpm 27/27, arch 27/27, PROOF_RC=0 — and the deb removal runs the kernel's
own postrm hooks in a container, so the clean exit is not an artefact of skipping them.

Refs #1280.

* pkg-proof: the memlock file has to be READ, not just present — and a first attempt that passed for the wrong reason

The config package's limits.d file was only ever checked as content ('2 lines, unlimited'). The NPU
runtime locks command buffers and fails without it, so a correct-looking file at a path pam_limits does
not read would be a confusing user-facing failure. Two rows now prove it is read:

  the memlock file is what pam_limits reads   write 4096 into the installed file, log in as a fresh
                                              user, and that login must report 4096
  the shipped limit reaches a login session   put the shipped file back, same login, ulimit -l: unlimited

4096 and not 8192 on purpose: the first version wrote 8192, which happened to equal the container's
inherited memlock, so it 'passed' without proving anything — lowering is always permitted, so only a
LOWER value can only have come from the file.

And the second row needs --cap-add=sys_resource: a container's default capability set excludes
CAP_SYS_RESOURCE, so raising a hard limit to unlimited silently fails and the session keeps the
container's 8192. Measured both ways (with the flag: unlimited; without: 8192); the three family lines
in this script's header now carry the flag, with a note saying why. A real machine's root has the
capability, so this is the container being made to behave like one.

deb 31/31, rpm 29/29, arch 29/29 rows PASS, PROOF_RC=0. Refs #1280.

* pkg-proof: the distribution-kernel path is proved on its own (--skip-kernel)

The most common user path had no proof as a unit: the docs say a machine that keeps its distribution's
kernel takes only the three driver/config packages, but every run so far installed the kernel packages
too. The harness now detects whether the directory carries kernel packages and, when it does not, prints
'INFO no kernel packages in this dir' and skips the kernel rows instead of failing them.

Two bugs found by running it, both mine:

* with the kernel block skipped, krel was never set, and under set -u the later [ -n "$krel" ] was a
  fatal unbound-variable error — the run printed 22 PASS and then exited 1 before the summary. krel is
  now initialised empty.
* the guard needed to wrap the kernel install/verify block as well as the removal block; the first patch
  only wrapped the removal, so --skip-kernel still tried to dpkg -i a glob that matched nothing.

Measured: --skip-kernel dir in ubuntu:26.04 -> 22 PASS + 1 INFO, ending with 'the in-tree module file is
restored'; and the with-kernel path still 31/31 PASS, RC=0, so the restructuring did not cost a row.

Refs #1280.

* docs(packaging): the row counts in the install rows must match what the harness prints

Self-audit of the section this PR edits: the three install rows still claimed 24/22/22 rows PASS, which
was right when #1324 merged and is wrong on this branch, where the harness emits 31 (deb) and 29 (rpm,
arch) after the restore, kernel-removal and memlock rows. A row that tells the reader to run
scripts/pkg-proof.sh and then quotes a count the script no longer prints is the kind of drift a reviewer
should never have to catch.

Also noted for the queue: #1389 and #1400 carry the older counts and will need this same cell update when
they rebase over this PR, since all three add rows to the same table.

---------

Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>